System and method for control and prevention of fraudulent use of financial services cards

ABSTRACT

A system and method is provided for fraud detection includes using information broadcast by devices and resources in the immediate vicinity of a mobile device, or by sensors located within the mobile device itself, to ascertain and make a determination of the immediate environment and state of the mobile device. If the mobile device is determined to be outside a predetermined range of an ongoing transaction, the transaction may be denied.

CROSS-REFERENCE TO RELATD APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 12/804,448, filed Jul. 21, 2010, and a continuation-in-part ofU.S. patent application Ser. No. 12/921,153, filed Jan. 25, 2011, whichare hereby incorporated by reference in their entireties as if fully setforth herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the delivery, discovery, management andcontrol of information to mobile consumers, and to the efficient use andcontrol of these resources to consume and generate information.

2. Description of the Related Art

Financial services cards, such as debit, credit, and ATM cards, areubiquitous. Fraud prevention is an increasingly difficult task.

Usage of credit and debit cards is checked at a site of a transaction.Typically, the card's magnetic strip is read and transmitted to thefinancial services provider. If the number is valid and the credit limitis not exceeded, the transaction will typically proceed. The clerk atthe site of the transaction may ask for additional identificationinformation and a signature, but these are often circumvented, if thecard is stolen.

An ATM card, on the other hand, requires a user to enter a personalidentification number (PIN). At an ATM machine before a transaction isallowed. Again, however, PINs may be hacked or otherwise ascertained bythose intent on fraud.

As such, there is a need for an improved system and method for detectingfraudulent use of debit, credit, and ATM cards.

SUMMARY OF THE INVENTION

These and other drawbacks in the prior art are overcome in large part bya system and method according to embodiments of the present invention.

A fraud detection system in accordance with embodiments as claimed makesuse of a customer's cellular telephone (i.e., smart phone or othermobile device). A financial service provider may arrange with atelephone service or other provider to provide a fraud preventionservice. The customer may be provided with an app and may register hiscell phone number and financial card number(s) with the service. When acard transaction is detected, the financial service providercommunicates with the telephony service provider to determine a locationof the cell phone. If the cell phone and the transaction are co-located,the transaction may proceed normally.

However, if the cell phone and the transaction are greater than apredetermined distance apart, the financial services provider may send(or cause to be sent) a message to the cell phone. The message can be atext message, querying the user for confirmation of the transaction, ormay be a message causing the cell phone to activate an app. The user cansend a reply to the text message or provide inputs as desired to theapp, both of which can be received back by the financial servicesprovider. Depending on the customer's response, the transaction can beallowed to proceed, or can be denied.

In addition, or in the alternative, the financial services provider mayprovide a message to the site of the transaction, querying the user foradditional information. For example, the screen on an ATM machine mayquery for an additional PIN (or question, e.g., mother's maiden name)before allowing the transaction to proceed.

A fraud detection method in accordance with embodiments as claimedincludes a financial services provider detecting an ongoing financialcard transaction, the detecting including determining a location of theongoing financial card transaction; determining a location of a cellphone associated with a registered user of the financial card responsiveto the detecting the ongoing financial card transaction; and if thelocation of the ongoing financial card transaction and the location ofthe cell phone are substantially the same, allowing the transaction toproceed. In some embodiments, the method further includes, if thelocation of the ongoing financial card transaction and the location ofthe cell phone are a predetermined distance from one another, providingcontent to the cell phone indicative of the ongoing financial cardtransaction.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features, and advantages made apparent to those skilled in theart by referencing the accompanying drawings. The use of the samereference symbols in different drawings indicates similar or identicalitems.

FIG. 1 illustrates an exemplary system according to embodiments of thepresent invention.

FIG. 2 illustrates a CL according to embodiments of the presentinvention.

FIG. 3 is a flowchart illustrating operation of embodiments of thepresent invention.

FIG. 4 is a diagram of an exemplary system map according to embodimentsof the present invention.

FIG. 5 is a diagram of an exemplary system map according to embodimentsof the present invention.

FIG. 6 is a flowchart illustrating operation of embodiments of thepresent invention.

FIG. 7 is an exemplary SDP in accordance with embodiments of the presentinvention.

FIG. 8 is an exemplary user device in accordance with embodiments of thepresent invention.

FIG. 9 is a flowchart illustrating operation of embodiments of thepresent invention.

FIG. 10 is a diagram of a system in accordance with embodiments of thepresent invention.

FIG. 11 is a diagram schematically illustrating operation of embodimentsof the present invention.

FIG. 12 is a flowchart illustrating operation of embodiments of thepresent invention.

FIG. 13 is a flowchart illustrating operation of embodiments of thepresent invention.

FIG. 14 is a flowchart illustrating operation of embodiments of thepresent invention.

FIG. 15A and FIG. 15 B are flowcharts illustrating operation ofembodiments of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Environment Map System

In accordance with embodiments of the present invention, a system andmethod is provided for using information broadcast by devices andresources in the immediate vicinity of a mobile device, or by sensorslocated within the mobile device itself, to ascertain and make adetermination of the immediate environment and state of the mobiledevice. This determination may be used to control and manage the actionsthat the device is asked to carry out by or on behalf of the user.Alternatively, this determination may be used to provide a user of themobile device with recommendations, e.g., for apps particularized to thedevice environment and state.

Advantageously, a carrier can define hundreds of device profiles andautomatically and dynamically associate them with user devices, based onthe device sensing its environment. The profiles allow or disallowcertain actions or combinations of actions, as will be described ingreater detail below.

Embodiments of the present invention address locating mobile devices ina telecommunications network that uses a mechanism of “paging requests”by certain network elements and “location updates” by mobile devices toupdate and maintain a database called the Home Location register (HLR).The term “location” typically refers to the cellular site (cell site)within which the mobile device was last known to be located, althoughother location methods, including satellite or triangulation-basedmethods, may be employed.

In accordance with embodiments of the present invention, paging requestsand location updates include not only cell site information, but alsothe availability of other access networks to the mobile device such asWiFi, Bluetooth, WiMax, etc. Moreover, any other resources, e.g.,display devices, that could be used in conjunction with the mobiledevice that are “attached” to the new access network and which“announce” their capabilities and availability are also included in theupdates. Internal sensor information, such as device orientation, motionsensors, etc., may also be provided.

The information so obtained from the environment surrounding a mobiledevice is captured in a series of update messages, referred to asresource updates, by a network facility that processes and stores themessages.

In an exemplary embodiment of the present invention, the mobile devicecontains a registry wherein all applications are authenticated andregistered before they can be used in the mobile device. The registrymay additionally contain a profile stating what resources an applicationneeds. A network facility uses an application profile and theinformation obtained from resource updates to dynamically assign aplurality of profiles to the mobile device. A profile may be re-assignedand modified whenever the resource updates or the registry informationin the mobile device warrant a change based on service logic executingin the network facility.

Consider, for example, a mobile device that is engaged in a voicetelephone call connected to a circuit-switched network. Assume themobile device contains applications for streaming mobile video and SMStext messaging, the applications registered within the registry of themobile device. The mobile device will have an associated profile in thenetwork facility that details the resources available to the mobiledevice, i.e., the circuit-switched network, the mobile video and SMSapplications, and any resources needed by the applications.

Now, assume a Bluetooth access network announces itself, itscapabilities and its resources. For example, the Bluetooth network mayannounce its type is “automobile” and that it supports a display devicewith certain attributes, e.g., resolution, size, etc. Assume the mobiledevice attaches itself to the new network.

The mobile device will update its registry to include the Bluetoothnetwork and its associated display device. Resource updates from themobile device to the network facility likewise now list the new accessnetwork available to the device (Bluetooth), and any resources that havebecome available, i.e., the new display device.

This causes the network facility to assign a new profile to the mobiledevice wherein delivery and display of mobile video may now beeffectuated on the newly discovered display device, i.e., the monitor inthe automobile. Moreover, a policy restriction stated by the serviceprovider preventing SMS messages from being received and initiated whilein an automobile may cause the registry to disable the SMS application,thus preventing the user from launching or receiving SMS messages.

Thus, the user may now view mobile content on the automobile display,rather than on the display of the mobile device, and may not initiate orreceive SMS messages while connected to the automobile's Bluetoothnetwork. Alternatively, the service provider may choose to display awarning message to the user without disabling any of the applications inthe mobile device.

Similarly, the device internal sensors may identify a particularphysical orientation, location or other characteristic of the device,and cause the network facility to enable or disable based thereon. Forexample, if the device is being held to the ear, then a rule may beprovided that video content is on the automobile display rather than themobile device display. Alternatively, content may be displayed that isrelated to the sensory information obtained from the device, e.g., acoupon may be displayed indicating an event in close proximity to thecurrent location of the device.

Turning now to the drawings and, with particular attention to FIG. 1, adiagram of a telecommunications system 100 according to an embodiment ofthe present invention is shown. The telecommunications system 100 mayinclude a network facility, such as a service delivery platform 102,which may include or be in communication with a resource map 104, aresource profile 106, a recognition unit 115, and an apps database 117.

As will be explained in greater detail below, the resource map 104contains an environment map of resources available to particular users,while the resource profile 106 defines particularized rules for makingthose resources available. The recognition unit 115, as will beexplained in greater detail below, may be implemented as, or including,an inference engine and contains matching rules for comparing accesspolicies to the user device's environment maps. That is, the servicedelivery platform 102 makes the resources available to the user devicesin accordance with the resource map 104, profile 106, and recognitionunit 115. In addition, the recognition unit 115 may include an appsrecognition unit 118 for recommending particular apps to a user based onthe environment or resource maps. That is, the apps recognition unit 118can process one or more matching rules associated with a mobile device'senvironment to access particular apps from the apps database 117.

The service delivery platform 102 may include or be in communicationwith one or more user devices 108, and one or more Home LocationRegister (HLR) databases 116. Typically, as will be explained in greaterdetail below, an HLR 116 is provided for each cell site in the networkto which the user device is registered. The user devices may furtherinclude or be in communication with resource registries 110,capabilities lists (CL) 112, and resource monitors 114.

As will be explained in greater detail below, the resource monitor 114monitors the network and resource environment (either passively oractively) for devices or resources that have become available orunavailable.

The capabilities lists 112 are lists maintained by all network devicesand resources. Specifically, it is envisaged that networks and devices,i.e., all resources, contain an internal capability list (CL) thatcontains not only the identification number of the resource but alsoattributes that may be of interest and use to applications. For example,a network CL may show the bandwidth, average latency, etc. A storagedevice CL may show the amount of available storage, the random accesstime, etc. A display device CL may show the resolution, number ofpixels, etc. Indeed, the attributes in the CL for most popular devicesand networks could be standardized. A particular device or entity's CLmay be updated when it receives a CL from other resources.

The resource registries 110, on the other hand, are registriesmaintained by the user device of CLs of other devices that are currentlyavailable to it. FIG. 2 illustrates an exemplary CL for a display devicethat would be maintained in the registry of, say, a mobile telephone.Attributes in the CL describe the capabilities of the resource, itsexternal interfaces, and intrinsic properties. For example, in the caseof a display device, this can include resolution, display size, refreshrate, etc.

In certain embodiments, the user devices 108 may be implemented astelephones, cellular telephones, PDAs, computers, hard or soft clients,etc. While typically implemented as a smartphone, the user devices 108also may be embodied as personal computers implementing a Windowsoperating system and the Explorer web browser. The user devices 108 thusmay include telephony and other multimedia messaging capability using,for example, peripheral cameras, Webcams, microphones, and speakers (notshown) or peripheral telephony handsets.

In general, while the user devices 108 may implement one or more of thesystems and methods described herein, the user devices also mayimplement one or more client devices or programs that communicate withservices that implement such systems and methods provided remotely. Incertain embodiments, the system 100 may also include other hardwareand/or software components (e.g., gateways, proxy servers, registrationserver, presence servers, redirect servers, databases, applications,etc.).

The devices may also contain sensors for the state of the device and/orthe state of its immediate environment, such as temperature, locationand orientation. For example, several current mobile devices, such assmartphones, sense WiFi and cellular networks. Others sense theorientation of the device and allow the display to be used in either aportrait or a landscape mode, using a gravity-based pendulum sensor. Inaddition, proximity sensors turn the display off when the device is heldto the ear.

In accordance with embodiments of the present invention, such physicalsensors may be used to define not simply local characteristics of thetelephone, but may be sent to the registry and uploaded to the networkfor use in implementing and/or determining network and device accesspolicies. Such information can further be used by the network todetermine and recommend suitable content (ads, coupons, etc.) andsmartphone apps.

As will be discussed in greater detail below, in order to receiveinformation, a mobile device must be located by the network since itcould physically be anywhere in the geographical area Each mobile deviceperiodically generates a message called the location update that isrecorded in a Home Location Register (HLR) 116. The location updatemessage typically contains the identity of the cell site in which themobile device is currently located and some other network-relatedinformation, e.g., signal strength, etc.

Whenever the network needs to reach a mobile device, e.g., to initiatean incoming voice call, it sends a paging request to the last cell sitein which the mobile device was located. Upon receiving the pagingrequest the mobile device may respond to it. If, however, the mobiledevice has re-located to another cell site since the last locationupdate, the paging request goes unanswered.

In accordance with embodiments of the present invention, the locationupdate message from a mobile device 108 is further loaded withinformation about other resources that are currently “available” to themobile device 108. Specifically, resources “announce” or make availabletheir CLs. This may be achieved either by accepting a specific requeston a well-defined interface and responding to the request or by doing abroadcast. The current generation of RFID devices, by way of example,announce themselves through a broadcast mechanism, as do certain WiMaxand Wifi networks. The mobile device 108 receives the announcements andaggregates them into one or more resource updates. In some embodimentsof the present invention, the announcements include other device CLs.The mobile device 108 periodically broadcasts these resource updates,which are then received by the service delivery platform 102.

As can be appreciated, such updates from the user devices to the servicedelivery platform 102 via the HLRs 116 could be bandwidth and/orprocessing intensive. As such, in accordance with embodiments of thepresent invention, any of a variety of techniques may be used tominimize such effects. For example, less-bandwidth-intensive binaryencoding may be used for the uplink registry messages. Alternatively, oradditionally, rather than having the uplink occur every time the HLR isupdated, it may occur only every other time, or every tenth time, or anyother predetermined period. Also, rather than having periodic updates,in some embodiments, the registry upload may occur only if the registryitself has actually been updated.

Furthermore, the service delivery platform 102, in conjunction with therecognition unit 115, the resource map 104 and resource profile 106, mayimplement one or more databases (not shown) that will require speedy andfrequent updates. Accordingly, embodiments of the present invention maymake use of “active” databases to accommodate the heavy traffic.

Turning now to FIG. 3, a flowchart 300 illustrating operation ofembodiment of the present invention is shown. The particular arrangementof elements in the flowchart 300 is not meant to imply a fixed order tothe elements; embodiments can be practiced in any order that ispracticable. More particularly, the flowchart 300 illustrates theaggregation process in a mobile device for a plurality of

CLs

In a process step 302, the mobile device 108 receives or discovers a CL.Receipt or discovery may be an out-of-band process and may beaccomplished through the resource broadcasting or otherwise announcingpresence and/or the CL.

In a process step 304, the user device 108 and, particularly, theresource monitor 114, checks if the CL is from a previously knownresource. An affirmative response can lead to updating of the CL in theuser device's lists (typically, the . received CL may itself be updatedand thus different from that previously stored), in a process step 306.Once updated, the information is integrated into the next resourceupdate to the service delivery platform 102, as shown at process step312. More particularly, the information is loaded with the locationinformation to the Home Location Register 116, which provides it to theservice delivery platform 102. As noted above, this may be sent withevery HLR update, or on an event basis or some periodic basis, and/orusing a low bandwidth binary encoding.

If, in process step 304, the CL was determined to be unknown, theresource will be registered in the mobile device registry 110, in aprocess step 308. A new CL is created for the new resource from thereceived CL in a process step 310, and the new CL is integrated into aresource update, in a process step 312. Once a resource update is ready,the update is sent to another process 1000 that perpetually loops on atimer at process step 314, and periodically generates a resource update,at steps 316, 318.

As noted above, resource updates from mobile devices are received andstored by the Service Delivery Platform (SDP) 102. Using informationfrom the resource updates, the SDP 102 constructs a conceptual map 104of the immediate environment of a mobile device, generates a resourceprofile 106 of a current environment of the device, and uses therecognition unit 115 to allow or disallow functionality based on themap.

For example, shown in FIG. 4 is a user device 108 that has received CLsfrom other resources 402, 404, 406. The CLs 402, 406, 408 may be, forexample, a cell site, a display resource, and a network resource. Themobile device 108 integrates these CLs into a resource update 408 whichin turn is broadcast by the mobile device 108 and received and stored bythe SDP 102.

The stored representation of the environment is shown at 410 andincludes a cell site 412, a display resource 414 and a network resource416. The resources 412, 414, 416 correspond to the CLs 402, 404, 406,respectively. It is noted that the graphical representation of FIG. 4 isfor purposes of simplicity only; the typical environment map usesinternal digital computer data structures to effectively store objectssuch as CL 402, 404, 406.

In the example illustrated, the informational attributes of CL 402 maydescribe a cell site of a cellular network 412 with interface 420; theinformational attributes of CL 404 may describe a RFID display devicedepicted as 414 with interface 424; and the informational attributes ofCL 406 may describe a WiFi network depicted as 416 with interface 422.The mobile device itself is shown as a unitary structure 430 forpurposes of this depiction but will be discussed later.

Thus, with reference to FIG. 4, the environment map 104 of the mobiledevice 108 shows that the device is in association with a display device414 using interface 424, and has access to two networks 412 and 416using interfaces 420, 422 respectively, the former being a WiFi networkand the latter a cellular network.

The inventions discussed herein do not presuppose that a resource isnecessarily associated exclusively with a single mobile device.Resources may be shared between multiples of mobile devices. It is alsoenvisaged that the SDP 102 maintains an environment map for a pluralityof mobile devices and, typically, maintains one map for all mobiledevices in its purview.

As noted above, the environment map of mobile devices may be used toefficiently deliver to and receive information from the mobile devices.As an exemplary case, consider the problem of delivering video contentfrom a source to the mobile device whose map 104 is depicted in FIG. 5.

The mobile device 108 is associated with a display resource 414, acellular network 412 and a WiFi network 416. Also shown are a variety ofnetwork paths, 101, 201, 301, 501, 601, 701. Given the environment mapof mobile device 108, a service profile 106 (FIG. 1) may be associatedwith the device that specifies that video content from a content server502 may be delivered to either the mobile device 108 or to the displayresource 414 and may further define the network path for the delivery.

In particular, the SDP 102 may choose a network path 101, 201, 301 todeliver the video content to the display resource 424. Alternatively, itmay deliver the video content using the network path 101, 201, 501, 601,301 to the mobile device 108; or it may also use the network path 701,412. The service profile may further direct the mobile device 108 toconsume the video content or to “relay” content to the display resource424. Such a directive may be dictated by policies stated by the serviceprovider. The SDP 102 may contain service logic using cost functions tochoose any one of these paths. It may also use current network trafficand policies to prefer one path over the other possible paths.

If the SDP 102 chooses to deliver the video content to the displayresource 424 and not the mobile device 108, it may first seek permissionfrom the mobile device 100 by engaging in user dialog, such as via agraphical user interface. It is thus apparent that a user of a mobiledevice 108 may request video content from a server and in some cases, asdepicted in FIG. 5, the video content will be received and relayed bythe mobile device 108, to be displayed on a device 424 in closeproximity to the mobile device.

Continuing with the example shown in FIG. 5, if the environment map ofthe mobile device 108 depicts that the device is in association with,for example, a Bluetooth (WiFi) network 416 generated by an automobile,the system and method of the present invention may employ a recognitionunit 114 to examine the environment map 104 of a mobile device 108 torecognize that the mobile device 108 is in a pre-defined context, e.g.,in an automobile and may limit access to features and services inresponse.

This is explained further with reference to FIG. 6. The SDP 102 receivesresource updates in step 602, and determines whether a resource updateis for a new or a previously known mobile device (step 604). Steps 606and 608 incorporate the received resource update into the environmentmap 104. In step 610, a recognition unit 115 containing pre-definedpattern matching rules is invoked that examines the environment map 104for the mobile device 108 with the recently received resource update todetermine if the map matches any of the pattern-rules of the recognitionunit 115.

If a match is found, i.e., the mobile device 108 is determined to be ina pre-defined network or context or environment, e.g., connected to anautomobile wifi network 416, then the recognition unit 115 returns anaffirmative response and may apply a service provider policy to theenvironment of the mobile device, e.g., restrict SMS usage.

In another exemplary embodiment, the SDP 102 may dictate the networkpath chosen to deliver the video content to the display resource 424 andnot to the mobile device 108. The policy enforced by the SDP 102 onbehalf of the service provider may be the result of safetyconsiderations calculated by the service provider. Thus, the user of amobile device 108 in an automobile may view video content on theexternal display provided by the automobile.

Continuing further with the example depicted in FIG. 5, suppose themobile device 108 is to be used to transmit content to the network,i.e., in the uplink direction. Again, it is apparent, that the mobiledevice 108 may query the environment map 104 via the SDP 102 to select asuitable network interface to use for making the transmission.

The present embodiment envisages that computing, display, storage andnetwork resources may be abundantly available to a mobile consumer, andthe consumer may choose to use such resources through the system andmethod described in the present invention. Moreover, as the consumertravels, his environment and availability of resources changes, thechanges being recorded in the registries and environment mapcorresponding to the user's mobile device.

The description of the present embodiment, so far, has concentrated onthe external resources available to a mobile device 108, and not on theapplications available within the device itself. It is envisaged, aspreviously stated, that mobile devices contain a registry of allapplications that have been loaded on to a mobile device by the serviceprovider or by the user himself. Applications that are not registered inthe registry are considered as “rogue” applications and are outside thescope of the present invention.

As described earlier, the environment map for a mobile device depictsthe immediate environment of the mobile device and the SDP 102 assigns anetwork profile 106 to the mobile device based on the currentenvironment map 104. It is envisaged by the present invention that theSDP 102 is also aware of the applications within the registry of themobile device 108, and when assigning a service profile, may enforce oneor more policies on the profile that cause the enablement or disablementof certain applications in the mobile device or impact delivery ofinformation to the mobile device by other network elements.

Continuing with the example of FIG. 5, the exemplary depiction showsmobile device 108 in association with a WiFi network resource 416generated by an automobile. This association may be assumed to trigger apolicy that disables the web browser and the SMS applications in theregistry of the mobile device 108. Thus, the user of the mobile device108 will not be capable of launching the SMS or the web browserapplications from the mobile device. Furthermore, the service providermay trigger network elements to disable the delivery of messages to themobile device in question, e.g., by marking the status of the mobiledevice as “unavailable” in the HLR will temporarily stop delivery ofmessages, including SMS messages, to the mobile device.

Turning now to FIG. 9, a flowchart 900 illustrating operation ofembodiment of the present invention is shown. The particular arrangementof elements in the flowchart 900 is not meant to imply a fixed order tothe elements; embodiments can be practiced in any order that ispracticable.

In a process step 902, a user device 108 receives or detects theaddition of one or more new programs, resources, or processes that maybe available to it. The new additions can include new CLs 112 and resultin an updated resource registry 110, as discussed above. In a processstep 904, the user device transmits the update to the SDP 102. Asdiscussed above, this can include the user device 108 transmitting alocation signal to the Home Location Register and piggy-backing the CLand registry information on top. The HLR 116 in turn provides theinformation to the SDP 102.

In a process step 906, the SDP 102's resource monitor 114 receives theupdate and provides the information to the resource map 104. Inresponse, in a process step 908, the resource map 104 determines a newenvironment map for the user device (and other devices). In a processstep 910, the SDP 102's recognition unit 115 accesses or updates theresource profile 106 of the particular device whose update has beenreceived. As noted above, the profile includes one or more rules basedon inferences from user contexts resulting from knowledge of the userposition, device orientation, etc.

In a process step 912, the SDP 102 can receive a service request from auser device. For example, as discussed above, this can include requestsfor video content or the like. In a process step 914, in response, theSDP 102's recognition unit 115 determines a user situation or device,i.e., accesses and applies the rules or policy for user access to theprogram or application or resource. Finally, in a process step 914, theSDP 102 can allow access per the rules.

Content Recommendation System and Method

As noted above, aspects of the present invention provide an app orcontent recommendation system based on sensory information received froma user device, typically stored as an environment or resource map.

FIG. 10 schematically illustrates a system for providing apps andrecommendations in accordance with embodiments of the present invention.The system includes a user device 108 such as a mobile device orsmartphone, including for example, a display screen of apps 1002 and anapp store icon 1004. Typically, a user can click on the app store icon1004 to communicate with an app store, browsing, selecting, and payingfor selected apps.

The app store is typically provided by a service provider or servicedelivery platform 1008, which may maintain a database of the availableapps 117. As will be discussed in greater detail below, the serviceprovider 1008 can operate a resource or environment map 104 and acontroller such as an app recognition unit 118 in accordance withembodiments of the present invention. The app recognition unit 118 mayimplement an inference engine to determine one or more situationalprofiles and recommend apps or services (or other content, such ascoupons, or other advertisements, or messages, etc.) to the user, aswill be explained in greater detail below. In addition, the serviceprovider 1008 may operate or be in communication with an accountingmanager 1010 which tracks the number of times a particular app isrecommended (or a coupon or advertisement is sent), for charging a feefrom an app provider. The app recognition unit 118 may include or be incommunication with a sensor rules database defining rules, as will beexplained in greater detail below.

In addition, the system may include an app provider 1006. The appprovider 1006 may be a third party provider of an app that is approvedand carried by the app store or, indeed, a provider of coupons, etc. Inaccordance with embodiments of the present invention, the app provider1006 can pay a fee and provide an API defining one or more rules basedon the sensory data in the environment map.

Alternatively, the service provider 1008 can build the API based on appprovider inputs. As will be explained in greater detail below, whenthere is a “match” to one or more sensor based criteria, the app orother content can be recommended and the app provider 1006 can becharged a “hit” fee. In some embodiments the service provider 1008 mayitself be the app provider.

In either case, in certain embodiments, a rule has the symbolic form “IfX & Y & Z & . . . then A,” where X, Y, and Z are antecedents (i.e., oneor more sensor-based conditions), and A is the consequent. In thisembodiment, the “&” represents a logical AND. It is noted that in otherembodiments, a rule may have or include a logical OR as well. Typically,the antecedents are related to the situation and environment of the cellphone itself, although one or more external events from informationsources may be correlated.

110891 In accordance with embodiments of the present invention, theconsequent is one or more situational profiles which can result in therecommending of one or more particularized apps or applications or othercontent, such as coupons or advertisements. That is, an app provider1006 can contract or otherwise arrange to have its app or content sentor recommended to a user based upon satisfaction of one or moresensor-based antecedents, that is, the matching of a situationalprofile. It is noted that a particular set of antecedents could have oneor more associated situational profiles.

It is envisaged that an app provider 1006 could contract with theservice provider or app store provider for exclusive or non-exclusive“rights” to a particular situational profile. If the user then acceptsthe recommended app, installing it on his mobile device, then the useris “assigned” the situational profile. The next time the situationarises, and pursuant to the situational profile, the app can beactivated. As can be appreciated, the user can be assigned any number ofsituational profiles.

In addition, any number of antecedents may be defined. An example of asensor-based condition is handset is located in an environment whereambient noise level is higher than a critical level (X), and the handsetis set to audible ring tone (Y). An example of a situational profile Awould be that the user is attending a concert. A corresponding app mightbe to “turn on vibrating mode.” Thus, if X and Y, then A. That is, theuser can receive, e.g., a text message or other message recommending anapp that would turn on the vibrating mode automatically in a noisyenvironment.

Exemplary rules can include sensing that a user is in motion andproposing an app that will hold incoming text messages; sensing that auser is in motion and reading a book and recommending an app that wouldread an online book or magazine; sensing that the user has suffered asudden deceleration and recommending an app to dial 911 or informauthorities; sensing that a user has entered a high crime area andrecommending an app that turns on tracking and issues a warning; sensingthat a user is sailing and recommending a weather monitoring app;sensing that a user is attending a music festival and recommending anapp that has a schedule. In each case, of course, rather thanrecommending an app, the system could send a coupon or otheradvertisement or content. For example, if the user is detected as beingrelatively near a coffee shop, the system could send a coupon.

As shown in FIG. 11, operation of such a rules-based app and contentrecommendation system is essentially transparent to the user. As shownat 1102 a, a user device 108 can receive a text message 1104 in responseto the satisfaction of the conditions defined by the antecedents, aswill be described in greater detail below. The text message can defineand include a link to the associated app or apps. It is noted thate-mail or other messaging could be employed. Binary SMS messages couldalso be used to automatically program and instruct the device toundertake certain actions, e.g., enable and disable certain functions.

As shown at 1102 b, clicking the text message at 1102 a can cause themobile device to open or navigate to an app store 1106 which includesthe app or apps in question. As shown at 1102 c, the user can thenselect and download the recommended app or apps. Similarly, the messagecould provide a coupon and a link to either the advertiser web page or alink to download the e-coupon.

It is noted that, while discussed in terms of a third-party appprovider, a service provider 1008 could also define rules forrecommending apps and could, indeed, recommend more than one app for aparticular situation defined by a situational profile, and from one ormore app providers.

Once a situational profile has been assigned to a user, it may be usedto provide a solution to the “complete the search” problem discussedearlier. That is, content or recommendations can be made to a userwithout requiring user input. A situational profile describes aninference made by the various components of the system (i.e., thesensory data, the rules database, the environment map). The inferencecan be used as a targeting mechanism for showing advertisements andother relevant content, where the targeting and “relevance” criteria aredetermined by the situational profile.

Operation of embodiments of the present invention may be illustrated byway of the following nonexclusive examples.

Example 1: Suppose a mobile device/smartphone user is attending theopera and brings with him the device 108. The device's location may bereported to the service provider 1008, for example, by the HLR reportingscheme described above, or by any suitable method, such as a GPS (globalpositioning system) type system (not shown). In addition, one or moreother sensor-based conditions, such as a level of ambient noise or thedevice remaining still for a predetermined period, may likewise bereported. This information may be stored by the service provider 1008,for example, in conjunction with an environment map 104, as discussedabove. The information may additionally, or alternatively, be providedto an inference engine 118, which has access to the sensor rulesdatabase. The inference engine 118 may access a rule and decide thatthere is a fit to an “attending opera” situational profile. A rule basedon these antecedents might be, for example, to recommend an app toautomatically mute, shut off the device, or activate a vibrate mode. Theservice provider 1008 can then transmit a message recommending the mute,vibrate, or shut down app. If the user decides to purchase and/orinstall the app, then the situational profile may be assigned to theuser and the next time that situation arises, the app is activated andthe device is muted, switched to vibrate, or turned off. The situationpursuant to the profile may then be detected locally or in conjunctionwith the service provider 1008.

In addition, or alternatively, the system can infer that the user is atthe opera and send a message advertising a recording of the performance.An associated link could be to a site where the recording could bepurchased.

Example 2: Suppose the user has taken his smartphone 108 while sailingon Lake Michigan. The user device 108 transmits sensor information, suchas location, speed, or indicia of continuous orientation changes (i.e.,from bobbing up and down on waves). The inference engine 118 receives oraccesses this information and determines if there is a rule andsituational profile. A rule, for example, might be to recommend a squallor weather warning app when the user is detected sailing. If the userinstalls the app, then the next time he meets the situational profile,the weather warning app may be activated.

Example 3: In this example, more than one situational profile arises inconjunction with a particular set of antecedents. Each of the “matched”situational profiles can be associated with its own unique set ofrecommended apps.

A user is in his automobile circling a given block that is known tocontain a Starbuck's. The service provider 1008 receives the “circling”and “Starbuck's” information into the environment map 104, which isaccessed by the inference engine 118. The inference engine 118 may theninfer one or more situational profiles that may be associated with theseantecedents. The service provider 1008 can then send recommendationsbased on the situational profiles.

One such situational profile that may be associated with theseantecedents is that the user is attempting to buy a cup of coffee. Inthis case, the user may receive a recommendation for an app that willadvise the user whenever he is near a Starbuck's. Alternatively, or inaddition, the user could receive other recommendations in response tomatching this situational profile. For example, the user could receive arecommendation for an app that provides an e-coupon for Dunkin Donuts.

Another situational profile that might be associated with theseantecedents is that the user is simply trying to find an open parkingspace. In this case, the inference engine 118 could cause arecommendation for an app that monitors public or private parking spacesthat might be available. If any of these apps is installed, the nexttime the user is detected in such a situation, the app or apps can beactivated. Alternatively, the user could be provided with a couponinline or attachment or link to a coupon for a nearby parking garage.

Example 4: Suppose the service provider 1008 has an arrangement with (oris) a credit or debit card provider to report usage information, i.e.,external events can be in the antecedent. Suppose then, that a user'scredit card or debit card is detected in use at a particular location,different than a location of the user's mobile device. A situationalprofile could be generated or assigned that defines a potentialfraudulent use of the card. The service provider 1008 can send either arecommendation for an app to the user that notifies him of suchsituations, or simply a recommendation to check on the status of thecard. Alternatively, the situational profile or the recommendation mayalso specify an action to be undertaken by the user that would validateor verify the external events. For example, the credit card transactioncould be validated by requesting an entry of a personal identificationor code. This fraudulent warning service could be provided, i.e., paidfor by either the user himself signing up to receive such warnings, orby the store owner who wants to ensure legitimate transactions, thetelecommunications service provider, or the credit card company. Thatis, any of these entities could subscribe to the particular situationalprofile.

Example 5: In addition to debit and credit card transactions, theservice provider 1008 can report usage information regarding usage of anATM card. For example, if an ATM card is detected during a transactionwith or in association with an ATM machine at a location different fromthe user's mobile device, a situational profile could be generated orassigned that defines a potential fraudulent use of the card. Theservice provider 1008 can send either a recommendation for an app to theuser that notifies him of such situations, or simply a recommendation tocheck on the status of the card. Alternatively, the situational profileor the recommendation may also specify an action to be undertaken by theuser that would validate or verify the external events. For example, theATM transaction could be validated by requesting an entry of a personalidentification or code into the mobile device. This fraudulent warningservice could be provided, i.e., paid for by either the user himselfsigning up to receive such warnings, or by the ATM card or ATM serviceprovider who wants to ensure legitimate transactions, thetelecommunications service provider. That is, any of these entitiescould subscribe to the particular situational profile.

This is shown at a high level more particularly with reference to FIG.15A. A service provider/fraud detection system 1554 maintains or is incommunication with a database 1558 that stores records 1559 associatingcell phone users and credit card/debit card information. The serviceprovider/fraud detection system 1554 may be implemented as one or moresecure servers in communication over a network, similar to the system(s)described above. In the example illustrated, the service provider/bankfraud detection system 1554 includes a fraud detection system 1553 and acell service provider 1553.

The records associate a user of a cell phone with his credit or debitcards and may be accessible by either or both of the cell serviceprovider 1555 and the bank fraud detection system 1553.

In operation, a user my employ his debit card 1551 at an ATM machine1552. Once the ATM receives the user's PIN, it communicates with thefraud detection system 1553. The fraud detection system 1553 thencommunicates with the cell service provider 1555 and may send theidentity of a party to be checked, i.e., the party whose card is beingused at the ATM. The cell service provider 1555 accesses the database1558 for the party's cell phone identification and operates to determinethe cell phone's location, in a manner similar to that discussed above.

If the phone is located within a predetermined distance of the ATM 1552,s shown by phone 1550 a, then the cell service provider 1555 willcommunicate with the fraud detection system 1553 to allow thetransaction. The fraud detection system will then do so in aconventional manner. Otherwise, if the cell phone is located somedistance away, such as shown at 1550 b, the fraud detection system willbe advised of this by the cell service provider 1555 and will disallowthe transaction. In addition, in some embodiments, the fraud detectionsystem 1553 may access or receive the cell phone or email address of theuser and send content such as a text or email message to the cell phoneadvising of the attempted usage of the card.

Turning now to FIG. 12, a flowchart 1200 illustrating operation ofembodiment of the present invention is shown. The particular arrangementof elements in the flowchart 1200 is not meant to imply a fixed order tothe elements; embodiments can be practiced in any order that ispracticable.

At a process step 1202, an app provider 1006 can develop an app (orother content) and an associated API defining one or more antecedents.As noted above, the app provider 1006 can be any developer, including,for example, a third-party, or can be the service provider itself, or aparty under contract with the service provider. Also as noted above, theAPI defining the rules can be defined by the app provider 1008 or can bedefined as a service offering by the service provider itself

At a process step 1204, the app and API are provided to the serviceprovider 1008 and/or installed in the service provider's network. It isnoted that, in some instances, the app and API may require additional oralternative approval by the manufacturer of the mobile device or itsoperating system.

Finally, in a process step 1206, the API is activated pursuant to theterms, if any, agreed-upon between the service provider 1008 and the appprovider 1006. Thus, the API may be used by the inference engine 118 toprovide recommendations for apps or other content to users based onwhether they meet the rules or match the corresponding profile(s).

Turning now to FIG. 13, a flowchart 1300 illustrating operation ofembodiment of the present invention is shown. The particular arrangementof elements in the flowchart 1300 is not meant to imply a fixed order tothe elements; embodiments can be practiced in any order that ispracticable.

In a process step 1302, a service provider 1008 operates a network,which can include an environment map 104 and CL system such as describedabove. The network also can implement the API or other programs formonitoring device condition and status and recommending particularizedapps and/or content. In particular, the service provider 1008 canimplement an inference engine 118 that can draw inferences from sensordata and one or more sensor rules.

In a process step 1304, the service provider network detects the userdevice environment. For example, this can include the status reportingsystem described above, and can include periodically accessing theenvironment map for such information. In a process step 1306, theservice provider 1008 implements the APIs, typically in conjunction withthe inference engine 118. As discussed above, this includes determiningwhether predetermined condition-antecedents have been met, i.e., asituational profile is identified. If so, then in a process step 1308,the service provider 1008 can access the corresponding app or apps orother content from the app database 117 and send a message to the userthat such an app or apps or content are available for download. In thecase of coupons and advertisements, the message itself may be thecontent.

In a process step 1310, the service provider 1008 can communicate withthe user device 108 which received the message. For example, the userdevice 108 can “browse” the app store or a coupon or advertiser linkover the Internet or over the provider's network. In a process step1312, the app or apps or other content can be sent to the user andactivated on his smartphone. Finally, in a process step 1314, ifdesired, the user can be billed or his account charged for the app orapps. In addition, in some embodiments, if desired, the service provider1008 can charge or receive a fee from the app provider whenever aparticular situational profile is “hit,” even if the corresponding appor coupon or advertisement is not downloaded. That is, the serviceprovider 1008 can charge a fee for every recommendation.

Turning now to FIG. 14, a flowchart 1400 illustrating operation ofembodiment of the present invention is shown. The particular arrangementof elements in the flowchart 1400 is not meant to imply a fixed order tothe elements; embodiments can be practiced in any order that ispracticable.

In a process step 1402, the user device 108 stores the app and thesituational profile, in a manner similar to that discussed above. Theuser device 108 may then monitor for the antecedents corresponding tothe profile, in a process step 1404. It is noted that, in otherembodiments, the monitoring profile may be implemented by the serviceprovider 1008.

In a process step 1406, the user device 108 may match the antecedents ofthe situational profile. Again, in alternate embodiments, the serviceprovider 1008 may perform the situational match, in a manner similar tothat discussed above. It is noted, too, that in some embodiments, theservice provider 1008 could provide additional recommendations for appsthat presumably meet the situational profile (although typically wouldnot recommend an app that has already been installed).

Finally, in a process step 1408, if there is a match, the user device108 activates the corresponding situational app. It is noted that, inalternate embodiments, the service provider 1008 detects the match tothe situational profile and transmits one or more commands to the userdevice to activate the corresponding app which can do so automatically.

As noted above, embodiments of the invention may be particularlyadvantageous in a credit card or ATM fraud setting. Operation in suchcontexts is shown more particularly with reference to FIG. 15B. Theparticular arrangement of elements in the flowchart 1550 is not meant toimply a fixed order to the elements; embodiments can be practiced in anyorder that is practicable.

Initially, a user may have downloaded a fraud prevention app or browserplug in provided, for example, by his bank of other financialinstitution and registered to receive the corresponding service. Thebank of other financial institution further may have arranged with aservice provider or other entity to operate one or more servers tointerface smartphone services with its fraud prevention service. In someembodiments, the bank itself functions at least in part as the serviceprovider.

At a process step 1552, the service provider/bank can detect a cardtransaction. As noted above, this can include debit, credit, or ATM cardtransactions. In some embodiments, the detection can comprisetraditional fraud or balance verification that normally proceed prior toallowance of a transaction. Such verification procedures can include abusiness identification from which a location of the transaction can bedetermined. In the case of an Internet or Web-based transaction, thesite or location of the transaction may be determined, e.g., by an IPaddress or other identification.

The service provider 1008 can access a database and determine if thereis a match to a telephone number and if the telephone number isregistered to the service, as shown in process step 1504. If there is nosuch service agreement, then the transaction can proceed normally, in aprocess step 1506.

If, however, the user is registered to the service, then in a processstep 1508, the location of the cell phone can be determined. This caninclude, for example, using the GPS or HLR techniques, as discussedabove. In some embodiments, it may be the case that a message is sent tothe cell phone user, telling him to activate an app so that the locationcan be determined. In other embodiments, the location can be determinedautomatically. In some embodiments, this may include one or more of thebank's servers communicating with the service provider from a remotelocation.

In a process step 1510, the service provider 1008 then determines if thecell phone and the transaction are occurring within a same site. If theyare, then again the transaction can proceed normally. If they are not,however, one or more alerts may be provided. In some embodiments, analert may be sent to the cell phone, as shown in process step 1512. Thismay be in the form of an automatic telephone call or a text or email orother electronic message. In addition, or alternatively, the serviceprovider 1008 may be informed (and who may then inform the transactionprovider), as shown in process step 1514.

The alert to the user may include a prompt for a confirmation message asshown at 1516. Typically, this would include instructions on a number tocall or a link to click that would require the user to manually confirmthat the transaction is one he is willing to allow. If the confirmationmessage is received back by the service provider at 1518, then thetransaction may be allowed to proceed normally. Otherwise, in a processstep 1520, the transaction will be denied.

It is noted that, in some instances, the service or transaction provideritself may want to automatically deny a transaction if the user and thecell phone are not co-located. Further, in some embodiments, a messagemay be provided via a screen or other interface at the site of thetransaction, offering instructions or explaining why the transaction isdenied. In the case of an ATM machine, for example, the machine itselfmay prompt the user for additional information.

FIG. 7 shows a block diagram of components of a service deliveryplatform or service provider implemented as a computing device 700,e.g., personal, or laptop computer or server. In some embodiments, thecomputing device 700 may implement one more elements of the methodsdisclosed herein

The system unit 11 includes a system bus or a plurality of system buses21 to which various components are coupled and by which communicationbetween the various components is accomplished. A processor 22, such asa microprocessor, is coupled to the system bus 21 and is supported bythe read only memory (ROM) 23 and the random access memory (RAM) 24 alsoconnected to the system bus 21. The computer 700 may be capable of highvolume transaction processing, performing a significant number ofmathematical calculations in processing communications and databasesearches. A Pentium™ or other similar microprocessor manufactured byIntel Corporation may be used for the processor 22. Other suitableprocessors may be available from Freescale Semiconductor, Inc., AdvancedMicro Devices, Inc., or Sun Microsystems, Inc. The processor 22 also maybe embodied as one or more microprocessors, computers, computer systems,etc.

The ROM 23 contains among other code the basic input output system(BIOS) which controls basic hardware operations such as the interactionof the disk drives and the keyboard. The ROM 23 may be embodied, e.g.,as flash ROM. The RAM 24 is the main memory into which the operatingsystem and applications programs are loaded. The memory management chip25 is connected to the system bus 21 and controls direct memory accessoperations including passing data between the RAM 24 and hard disk drive26 and removable drive 27 (e.g., floppy disk or flash ROM “stick”). A CDROM drive (or DVD or other optical drive) 32 may also be coupled to thesystem bus 21 and is used to store a large amount of data, such as amultimedia program or a large database.

Also connected to the system bus 21 are various I/O controllers: Thekeyboard controller 28, the mouse controller 29, the video controller30, and the audio controller 31. The keyboard controller 28 provides thehardware interface for the keyboard; the mouse controller 29 providesthe hardware interface for the mouse 13 (or other cursor pointingdevice); the video controller 30 is the hardware interface for the videodisplay 14; and the audio controller 31 is the hardware interface for aspeaker and microphone (not shown). It is noted that while the variousI/O controllers are illustrated as discrete entities, in practice, theirfunctions may be performed by a single I/O controller known as a “superI/O.” Thus, the figures are exemplary only.

In operation, keyboard strokes are detected by the keyboard controller28 and corresponding signals are transmitted to the microprocessor 22;similarly, mouse movements (or cursor pointing device movements) andbutton clicks are detected by the mouse controller and provided to themicroprocessor 22. Typically, the keyboard controller 28 and the mousecontroller 29 assert interrupts at the microprocessor 22. In addition, apower management system 33 may be provided which causes the computer toenter a power down mode if no activity is detected over a predeterminedperiod.

One or more network interfaces 40 enable communication over a network46, such as a packet network like the Internet. The network interfaces40 may be implemented as wired or wireless network interfaces operatingin accordance with, for example, one or more of the IEEE 802.11xstandards and may also or alternatively implement a Bluetooth interface.

One embodiment of the present invention is as a set of instructions in acode module resident in the RAM 24. Until required by the computersystem, the set of instructions may be stored in another computermemory, such as the hard disk 26, on an optical disk for use in the CDROM drive 32, a removable drive 27, or the flash ROM.

As shown in the figure, the operating system 50, resource monitor 104,resource map 106, resource profile(s) 114, and recognition unit 115 areresident in the RAM 24. The operating system 50 functions to generate agraphical user interface on the display 14.

Execution of sequences of the instructions in the programs causes theprocessor 22 to perform various of the process elements describedherein. In alternative embodiments, hard-wired circuitry may be used inplace of, or in combination with, software instructions forimplementation of some or all of the methods described herein. Thus,embodiments are not limited to any specific combination of hardware andsoftware.

The processor 22 and the data storage devices 26, 27, 32 in the computer700 each may be, for example: (i) located entirely within a singlecomputer or other computing device; or (ii) connected to each other by aremote communication medium, such as a serial port cable, telephone lineor radio frequency transceiver. In one embodiment, the computer 100 maybe implemented as one or more computers that are connected to a remoteserver computer.

As noted above, embodiments of the present invention may be implementedin or in conjunction with a telephone, such as a wireless or cellular“smart” telephone. An exemplary cellular telephone 800 includingcapabilities in accordance with an embodiment of the present inventionis shown in FIG. 8. In some embodiments, the cellular telephone 800 mayimplement one or more elements of the methods disclosed herein. Asshown, the cellular telephone includes control logic 802 and cellulartransceiver 804. The cellular transceiver 804 allows communication overa cellular telephone network, such as a GSM or GPRS based cellulartelephone network. The control logic 802 generally controls operation ofthe cellular telephone and, in some embodiments, implements CLs andresource registry, as well as other services or clients in accordancewith embodiments of the present invention.

The control logic 802 interfaces to a memory 818 for storing, amongother things, contact or address lists 107. The control logic 802 alsointerfaces to a user interface(s) 810. The user interface(s) 810 caninclude a keypad 820, speaker 822, microphone 824, and display 826. Thekeypad may include one or more “hard” keys, but may be implemented inwhole or in part as a cursor pointing device in association with one ormore “virtual” keys on the display 826. In general, a user may make useof the keypad 820 and display 826 to enter contact information, and mayspeak into the microphone to provide the audio input(s). It is notedthat other interfaces, such as voice-activated interfaces may beprovided. Thus, the figure is exemplary only. In addition, a Bluetoothor WiFi interface 806 may be provided. A memory 808 for storing programcode and data, such as the CL 112 and registry 110, also may beprovided.

While specific implementations and hardware/software configurations forthe mobile device and SDP have been illustrated, it should be noted thatother implementations and hardware configurations are possible and thatno specific implementation or hardware/software configuration is needed.Thus, not all of the components illustrated may be needed for the mobiledevice or SDP implementing the methods disclosed herein.

As used herein, whether in the above description or the followingclaims, the terms “comprising,” “including,” “carrying,” “having,”“containing,” “involving,” and the like are to be understood to beopen-ended, that is, to mean including but not limited to. Only thetransitional phrases “consisting of” and “consisting essentially of,”respectively, shall be considered exclusionary transitional phrases, asset forth, with respect to claims, in the United States Patent OfficeManual of Patent Examining Procedures.

Any use of ordinal terms such as “first,” “second,” “third,” etc., inthe claims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another, or thetemporal order in which acts of a method are performed. Rather, unlessspecifically stated otherwise, such ordinal terms are used merely aslabels to distinguish one claim element having a certain name fromanother element having a same name (but for use of the ordinal term).

111461 The above described embodiments are intended to illustrate theprinciples of the invention, but not to limit the scope of theinvention. Various other embodiments and modifications to thesepreferred embodiments may be made by those skilled in the art withoutdeparting from the scope of the present invention.

What is claimed is:
 1. A fraud detection method, comprising: a financialservices provider detecting an ongoing financial card transaction, thedetecting including determining a location of the ongoing financial cardtransaction; determining a location of a cell phone associated with aregistered user of the financial card responsive to the detecting theongoing financial card transaction; and if the location of the ongoingfinancial card transaction and the location of the cell phone aresubstantially the same, allowing the transaction to proceed.
 2. A frauddetection method in accordance with claim 1, further comprising, if thelocation of the ongoing financial card transaction and the location ofthe cell phone are a predetermined distance from one another, providingcontent to the cell phone indicative of the ongoing financial cardtransaction.
 3. A fraud detection method in accordance with claim 2,wherein the content includes one or more text messages.
 4. A frauddetection method in accordance with claim 2, wherein the contentincludes one or more confirmatory messages.
 5. A fraud detection methodin accordance with claim 2, further comprising denying the transactionif a confirmation is not received back by the financial servicesprovider.
 6. A computer program product including at least one tangiblemachine-readable medium including program instructions for: detecting anongoing financial card transaction, the detecting including determininga location of the ongoing financial card transaction; determining alocation of a cell phone associated with a registered user of thefinancial card responsive to the detecting the ongoing financial cardtransaction; and if the location of the ongoing financial cardtransaction and the location of the cell phone are substantially thesame, allowing the transaction to proceed.
 7. The computer programproduct of claim 6, further comprising, if the location of the ongoingfinancial card transaction and the location of the cell phone are apredetermined distance from one another, providing content to the cellphone indicative of the ongoing financial card transaction.
 8. Thecomputer program product of claim 7, wherein the content includes one ormore text messages.
 9. The computer program product of claim 7, whereinthe content includes one or more confirmatory messages.
 10. The computerprogram product of claim 7, further comprising denying the transactionif a confirmation is not received back by the financial servicesprovider.